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Attorney Docket No . : S AFL-24 
ELECTRONIC TRANSACTION VERIFICATION SYSTEM 
Field of the Invention 

[0001] The present invention relates generally to authentication technologies, 

and more particularly, to verifying that a transaction, such as a credit card or an 
5 electronic transaction is authorized to proceed. 

Background of the Invention 

[0002] Credit card fraud is rampant. Criminals routinely misappropriate credit 

cards and associated account information to perpetrate unauthorized transactions. In 
our technology-bound society, these transactions are often handled electronically. 
10 While the advent of electronic credit transactions has been seen as a boon, it has been 

accompanied by certain vulnerabilities that criminals routinely exploit, costing 
industry and private citizens vast amounts of money and anxiety. One such 
vulnerability includes the absence of an independent, transactional-based system for 
determining whether the electronic transaction is authorized to proceed. 



[0003] More particularly, conventional electronic credit transactions presume 

for the sake of practical convenience and expense that the person in possession of a 
card or other credit account information is, in fact, authorized to access the account. 
For example, a restaurant patron may attempt to pay for a meal by presenting a waiter 
with a credit card. The waiter swipes the credit card through a card reader. The card 
reader electronically communicates with a processing center, which if that center 
recognizes the card data as a valid account, will (at least tentatively) authorize the 
transaction. In turn, a receipt may be printed for signature by the patron. The patron 
may or may not be the rightful owner of the credit card or may not otherwise be the 
person authorized to use the card. Similarly, online transactions proceed based on a 
similar presumption that the person entering some minimum amount of account 
identification information is authorized to charge purchases against the account. 
[0004] In the common scenarios described above, if the person presenting the 

card or account information is not the rightful owner or authorized user, the 
transaction will likely be approved if the account data is otherwise valid. The result 
will be a loss to the credit issuer, the business involved, and/or the rightful owner of 
the card. Those losses can mount significantly, not to mention the frustration, anger 
and anxiety created for the consumers bilked by criminal and fraudulent use of their 
credit account information. 

[0005] Efforts to battle credit card fraud are themselves costly, and often fail. 

Most proposals involve modifications to the cards, the readers, or other infrastructure 
changes that are difficult and costly to deploy, especially given that most of the cards 
and hardware are distributed out over millions of locations and people. Some of these 
proposals are impractical, while others are inconvenient and annoying. As a 



consequence, there exists a universal need for a more efficient, cost effective and 
otherwise improved manner for determining if an electronic-based credit or other 
financial transaction is authorized, especially without requiring new or different 
equipment or cards for the users and businesses that interface with consumers as part 
of the transaction. Similarly, many other types of electronic transactions occur where 
such improvements are desirable. 
Summary of the Invention 

[0006] The present invention provides an improved apparatus, program 

product and method for determining if an electronic transaction is authorized and 
should proceed. To this end, and in accordance with the principles of the present 
invention, before the electronic transaction is approved, the rightful owner or 
authorized user is automatically contacted via an identifying device correlated to that 
person who would normally be in the possession of, or otherwise accessible to, that 
person for verification that the transaction should proceed. When contacted, the 
transaction can be verified or refused through the identifying device by the rightful 
owner or authorized user, thus reducing substantially the risk of credit card fraud, for 
example. The foregoing generally capitalizes on equipment conventionally available 
to a user, and thus may not require changes to existing equipment and card 
requirements of users and businesses interfacing with consumers. 
[0007] In the restaurant and online examples described above, the identifying 

device may be the card holder's cellular telephone. When the credit card is swiped by 
the waiter, or is otherwise keyed in or entered online, the processing center determines 
that the account is valid and that the identifying device is the cellular telephone. The 
system automatically calls the card holder's phone. When the owner answers, she can 



enter a code as a sequence of buttons or speak into the phone, depending upon the 
type of verification required by the processing system (which will usually be 
determined in advance). If the proper code is entered by button or voice, or if the 
speech is recognized -as a biometric identifier for the owner, the transaction will be 
authorized and may proceed as normal at the purchasing end. If unrecognized or 
inaccurate, the transaction will not be authorized, and the potential that the card is 
being used illegally will have been terminated in that instance. 
[0008] Other identifying devices may be utilized, such as personal digital 

assistants ("PDAs"), pagers, or other handheld or laptop devices. For example, in an 
online example, the identifying device may be an email or instant message ("IM") 
facility accessible via the same or another communication device on which the online 
transaction is occurring. The authorized card holder is to enter certain responses in 
response to the email or IM, such as a password or the like. Or, the response may be 
via a biometric receiving device (such as a microphone or fingerprint reader) to 
receive the biometric authentifier for transmission to the central processing system for 
transactional verification. 

[0009] The likelihood of a criminal having both the credit card/information 

and the identifying device is significantly lower than the odds of the criminal having 
just the credit card/information. Such odds are exponentially reduced where the 
identifying device and authentication protocol incorporate use of a password and/or a 
biometric identifier (referred to as a Biometric Identification Record or BIR). A BIR 
generally comprises an electronically stored file correlated to a unique behavioral or 
physical characteristic of an individual. The individual may rely on the BIR as a form 
of identification or authentication. Common physical characteristics include 



fingerprints, voice recognition attributes and hand geometry, as well as facial and 
retinal/iris characteristics. Behavioral characteristics generally include electronic 
signatures and keystroke pattern, by way of example. 
[0010] To this end, one or more processing systems receive remote 

identification data from the identifying device. To this end, the processing system 
generates a request for remote data to prompt the user to enter the remote 
identification data into the identifying device. The request may be generated in 
response to the user initiating the request at a transaction terminal. The remote 
identification data is compared against stored authentication data associated with an 
account of an authorized user. While the comparison may be conducted at the 
identifying device, it is generally accomplished at the processing system. Verification 
is communicated to the transaction terminal in response to the comparison. 
Depending on the configuration of the transaction system, the transaction terminal 
either approves or denies the pending transaction. 

[0011] Additionally, while there will be certain modifications necessary at the 

processing center(s), the major infrastructure involved at the consumer and business 
end is left largely untouched. Instead, the authentication involves identifying devices 
that the user is expected to already possess. Most are also of the highly portable 
variety, and are commonly carried about with the user, such as cellular phones and 
wireless PDAs. Each device may be taken by a consumer to the location of a 
transaction, obviating the need for that location to provide special authenticating 
hardware. Moreover, the user can be contacted anytime they choose to undertake a 
credit transaction, or should a third party attempt to use the credit or other account 
data. The ready access to the identifying device further promotes speedy 



authorization. The result is a cost-effective method to reduce or eliminate credit card 
fraud, and without the need for complicated systems of cards, readers, and other 
complex attacks on the problem. 

[0012] Electronic transactions for purposes of this specification may include 

commercial transactions, as well as transactions involving access to controlled data, 
services or equipment. The present invention thus has application in private industry, 
personal and government arenas, to include credit exchange, personal, corporate and 
government security considerations. For instance, identification techniques in 
accordance with the present invention may be used to verify the authenticity of 
purchasers for credit, airline pilots and passengers, as well as that of corporate and 
military personnel accessing confidential information. Access to equipment may also 
be controlled with the present invention. 

[0013] Prior to approval of the transaction, the user may have an opportunity 

to review transactional data relating to the pending transaction, such as pricing 
information. Such precaution further mitigates incidents of erroneous transactions by 
requiring the user to both access the identifying device and affirmatively approve the 
particulars of the transaction with remote identifying data. Similarly, a corporate 
representative or parent may verify and approve a pending transaction initiated by an 
employee or child, respectively. Such control may be automatically instituted using a 
profile. 

[0014] Profiles may be used to further safeguard and streamline electronic 

transactions. A profile may contain programmatic rules of operation that stipulate 
how, when and where transaction verification processes are to be accomplished. For 
instance, a profile may designate a secondary identifying device to be used when a 
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primary identifying device is unresponsive. Certain types and times of transactions 
may receive additional scrutiny, and a profile may initiate disapproval of a particular 
transaction based on a predetermined condition and irrespective of matching data. 
[0015] By virtue of the foregoing, there is thus provided an improved 

mechanism for determining whether an electronic transaction is authorized to proceed 
that addresses above-identified shortcomings of known authentication and 
commercial transaction systems. These and other objects and advantages of the 
present invention shall be made apparent from the accompanying drawings and the 
description thereof. 
Brief Description of the Drawings 

[0016] The accompanying drawings, which are incorporated in and constitute 

a part of this specification, illustrate embodiments of the invention and, together with 
the general description of the invention given above and the detailed description of the 
embodiments given below, serve to explain the principles of the present invention. 
[0017] Fig. 1 is a block diagram of an embodiment of an authentication 

system in accordance with the principles of the present invention for determining 
whether an electronic transaction should proceed. 

[0018] Fig. 2 is a block diagram of a second embodiment of an authentication 

system in accordance with the principles of the present invention for verifying that an 
electronic transaction should proceed. 

[0019] Fig. 3 is a block diagram of an authentication system for determining 

whether a user seeking to operate a vehicle should be granted access to the vehicle in 
accordance with the principles of the present invention. 



[0020] Fig. 4 is a flowchart having method steps suitable for execution by a 

processing system of the system of Fig. 1. 

[0021] Fig. 5 is a flowchart having method steps suitable for execution by a 

user of the authentication system of Fig. 1. 

[0022] Fig. 6 is a flowchart outlining method steps for generating a profile of 

the authentication system of Fig. 1. 
Detailed Description of the Drawings 

[0023] Fig. 1 is a simple block diagram of an authentication system 10 for 

determining if an electronic transaction, such as a merchandise purchase, is authorized 
and should proceed. When a user 1 1 attempts to make a purchase on credit, they 
typically provide a credit card to a vendor operating a swipe machine, register, or 
other transaction terminal 12. Information from the card is read off of the card by the 
swipe machine, for instance, and is communicated over a communications link 1 3 or 
network to a processing system 14. The processing system 14 evaluates the 
information, usually along with a conveyed purchase amount, to see if the information 
corresponds to a valid account and the purchase amount is within acceptable limits. 
Assuming this is the case, the processing center 14 will conventionally send approval 
to the transaction terminal 12 at the vendor site, so that the sale may complete, 
receipts may be generated and the transaction may otherwise proceed as normal. 
[0024] Processes of the present invention interrupt conventional approval 

practices by holding back authorization sent from the processing system 14 to the 
vendor until an authorized user verifies the transaction using their cellular phone 15. 
That is, the processing system 14 communicates with the cellular phone 15 to retrieve 
a password, token, or BIR from the authorized user. To this end, the processing 
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system 14 may maintain a list of cellular phone numbers associated with authorized 
user(s). Thus, the authorized user may be automatically contacted via the cellular 
phone 15 or other identifying device that would normally be in the possession of or 
otherwise accessible to that person. When contacted, the transaction can be verified 
or refused using the cellular phone 15 by the rightful owner or authorized user. The 
system thus significantly reduces the risk of fraud or error. 

[0025] More particularly, a user 1 1 may attempt to purchase merchandise, for 

example, at the transaction terminal 12. The transaction terminal 12 contacts the 
processing system 14 in response to the user initiating the transaction at the terminal 
12. The processing system 14 then contacts the authorized user 1 1 via the cellular 
phone 15. Namely, the processing system 14 dials the number of the cellular phone 
15, causing it to ring. If the user has the cellular phone 15 on their person, the user 1 1 
may be prompted to depress a sequence of buttons on the phone 15 or speak a 
particular phrase that comprises remote identification data. That is, after reviewing 
data presented by the cellular phone 1 5 that describes the pending transaction, the user 
1 1 either approves or disapproves of the pending transaction by inputting remote 
identification data into the cellular phone 15. Such data may include token, password 
or biometric features where desired. The cellular phone 15 communicates the remote 
identification data back to the processing system 14, which in turn, compares the 
remote identification data to stored data to see if a match (within predetermined 
limits, if biometric) can be determined. If so, the processing system 14 may send 
authorization back to the transaction terminal 12. Otherwise, the processing system 
14 may communicate disapproval back to the terminal 12 using conventional 
processes. 

9 



[0026] The cellular phone 15 has features, such as a transmitter, receiver and 

keypad that are well suited for communicating data between a user and a processing 
system 14. The proliferation of cellular devices also makes its application in the 
context of the present invention very practical. However, while the identifying device 
of Fig. 1 may embody a cellular phone, another identifying device may comprise one 
or more of many devices configured to transmit and receive signals to and from a 
processing system 14. As such, typical identifying devices may include a pager, a 
personal digital assistant (PDA) and/or a laptop computer, among other devices. Such 
devices are typically strongly associated with the user, i.e., carried on the person of the 
user. As such, identifying devices commonly include devices that would be 
statistically unlikely for an unauthorized user to access. 

[0027] As shown in the system 10 of Fig. 1, the cellular phone 15 transmits 

and receives signals to and from a processing system 14 over link 16. For the 
purposes of the invention, the processing system 14 may represent most types of 
controllers, computer systems, processors or other programmable electronic devices 
capable of functioning as a processor, client and/or server computer. Where desired, 
the processing system 14 may be implemented using one or more networked 
computers or other controllers, e.g., in a cluster or other distributed computing system. 
[0028] The processing system 14 typically communicates directly or indirectly 

with a transaction terminal 12. A typical transaction terminal 12 includes a card slot 
reader at a vendor's, or a computer used to make an online purchase. However, 
aspects of the present invention may also apply to mechanical devices. For instance, a 
transaction terminal may include an ignition switch, among other mechanisms 
configured generally to receive a token and/or other identification associated with a 
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user account. For purposes of this specification, an account includes one or more 
records pertaining to a user or group of users. 

[0029] Fig. 2 shows an authentication system 20 that includes an identifying 

device 22 that receives remote identification data of a user 23. While the identifying 
device 22 may embody the cellular phone shown in Fig. 1, a suitable identifying 
device 22 may comprise most devices configured to transmit and receive signals to 
and from a processing system 16. The processing system 16, in turn, may 
communicate with an authorization server 24. Where so configured, the authorization 
server 24 is in communication with both a credit/data provider 25 and a transaction 
terminal 21. The transaction terminal 21 generally receives input originating from the 
user 23 and/or a merchant. 

[0030] System 20 includes at least one apparatus, e.g., one or more computers, 

such as the processing system 16. For the purposes of the invention, the processing 
system 16, as with most other devices or system components included in this 
specification and termed a "computer, "controller" or "processor," may represent 
practically any type of controller, computer system, processor or other programmable 
electronic device capable of functioning as a processor, client and/or server. Where 
desired, the processing system 16 may be implemented using one or more networked 
computers or other controllers, e.g., in a cluster or other distributed computing system. 
[0031] Processing system 16 typically includes a central processing unit 33 

comprising at least one microprocessor coupled to a memory 35, which may represent 
the random access memory (RAM) devices comprising the main storage of processing 
system 16, as well as any supplemental levels of memory, e.g., cache memories, non- 
volatile or backup memories (e.g., programmable or flash memories), read-only 
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memories, etc. In addition, memory 35 may be considered to include memory storage 
physically located elsewhere in processing system 16, e.g., any cache memory in a 
processor in computer processor unit (CPU) 33, as well as any storage capacity used 
as a virtual memory, e.g., as stored on a mass storage device 26 or on another 
computer coupled to/in communication with processing system 16. 
[0032] Processing system 16 also typically receives a number of inputs and 

outputs for communicating information externally. For interface with an operator, 
processing system 16 typically includes an interface 28 incorporating one or more 
input devices. Otherwise, operator input may be received via another computer or 
terminal. 

[0033] For additional storage, processing system 16 may also include one or 

more mass storage devices 26, e.g., a floppy or other removable disk drive, a hard disk 
drive, a direct access storage device (DASD), an optical drive (e.g., a CD drive, a 
DVD drive, etc.), and/or a tape drive, among others. Furthermore, processing system 
16 may include an interface 30 with one or more networks (e.g., a LAN, a WAN, a 
wireless network, and/or the Internet, among others) to permit the communication of 
information with other computers and electronic devices. It should be appreciated 
that processing system 16 typically includes suitable analog and/or digital interfaces 
between CPU 33 and each of components 26-44, as is well known in the art. 
[0034] Processing system 16 may be implemented using a multi-user 

computer such as a server computer, a midrange computer, a mainframe, etc. The 
identifying device 22 may also be implemented using a desktop, single-user computer 
or any other device having a processor and configured to transmit and receive signals 
to and from, for example, the processing system 16. As a result, the specifications of 
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the CPU's, memories, mass storage, user interfaces and network interfaces will 
typically vary as between the processing system 16 and identifying device 22. One 
skilled in the art should additionally appreciate that other hardware environments are 
contemplated within the context of the invention. 

[0035] Where direct, dedicated connections are not preferred or practical, 

processing system 16 generally interfaces with the authorization server 24 and/or 
identifying device 22 via a network 32. The network 32 may be public and/or private, 
wired and/or wireless, local and/or wide-area, etc. Moreover, the network 32 may 
represent multiple, interconnected networks. As shown in Fig. 2, for example, 
network 32 may include the Internet. 

[0036] The processing system 16 operates under the control of an operating 

system 34, and executes or otherwise relies upon various computer software 
applications, components, programs, objects, modules, data structures, etc. (e.g., 
identifying program 36, BioAPI 38 and biometric authentication program 40, among 
others. BioAPI 38 regards a programming interface supplied by biometric service 
providers that provides enrollment and verification services for installed biometric 
devices). Moreover, various applications, components, programs, objects, modules, 
etc. may also execute on one or more processors in another computer coupled to 
processing system 16 via a network, e.g., in a distributed or client-server computing 
environment, whereby the processing required to implement the functions of a 
computer program may be allocated to multiple computers over a network. 
[0037] In general, the routines executed to implement the embodiments of the 

invention, whether implemented as part of an operating system or a specific 
application, component, program, object, module or sequence of instructions, or even 
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a subset thereof, will be referred to herein as "computer program code," or simply 
"program code." Program code typically comprises one or more instructions that are 
resident at various times in various memory and storage devices in a computer and/or 
network of computers, and that, when read and executed by one or more processors in 
a computer or other device, cause that computer/device to perform the steps necessary 
to execute steps or elements embodying the various aspects of the invention. 
[0038] While the invention has and hereinafter will be described in the context 

of fully functioning computers and computer systems, those skilled in the art will 
appreciate that the various embodiments of the invention are capable of being 
distributed as a program product in a variety of forms, and that the invention applies 
equally regardless of the particular type of signal bearing media used to actually carry 
out the distribution. Examples of signal bearing media include but are not limited to 
recordable type media such as volatile and non- volatile memory devices, floppy and 
other removable disks, hard disk drives, magnetic tape, optical disks (e.g., CD-ROMs, 
DVDs, etc.), among others, and transmission type media such as digital and analog 
communication links. 

[0039] In addition, various program code described hereinafter may be 

identified based upon the application within which it is implemented in a specific 
embodiment of the invention. However, it should be appreciated that any particular 
program nomenclature that follows is used merely for convenience, and thus the 
invention should not be limited to use solely in any specific application identified 
and/or implied by such nomenclature. Furthermore, given the virtually endless 
number of manners in which computer programs may be organized into routines, 
procedures, methods, modules, objects, and the like, as well as the various manners in 
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which program functionality may be allocated among various software layers that are 
resident within a typical computer (e.g., operating systems, libraries, API's, 
applications, applets, etc.), it should be appreciated that the invention is not limited to 
the specific organization and allocation of program functionality described herein. 
[0040] Furthermore, embodiments consistent with the invention may be 

configured to authenticate people using applets and other such layers of software via 
an active hypertext document. As is well known in the art, applets may be used to 
generate active hypertext documents through which input data may be supplied for 
subsequent transmission. As discussed herein, identifying operations may be 
implemented by embedding one or more instructions within the active hypertext 
document to initiate the performance of the authentication by the processing system 
16. 

[0041] One or more applets may be configured for execution by an engine 42 

resident on the processing system 16. The engine 42 may process the applets to 
generate one or more active hypertext documents for transmission by a web server 44 
that also resides on the processing system 16. Such active hypertext documents may 
be downloaded to remote devices/computers. In one embodiment, such active 
hypertext documents may be processed by a web browser, which renders the 
documents on a client display at the authentication server 24 or identifying device 22 
in a manner well known in the art. Processing system 16 also typically receives a 
number of inputs and outputs for communicating information externally. As 
discussed herein, processing system 16 typically includes an interface for 
communication with the identifying device 22 and the authentication server 24. 
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[0042] As discussed herein, the authentication server 24 may include a 

networked computer similar to the processing system 16. For instance, the 
authentication server 24 may include a CPU, memory, interface, browser and other 
similar programming. However, one of skill in the art will appreciate that the 
hardware and software of the authentication server 24 may vary substantially from 
that of the processing system 16 per application specifications. In the context of an 
electronic transaction, a typical authentication server 24 likely comprises one or more 
servers in communication with merchants and creditors. 

[0043] The authentication server 24 may include software configured to route 

transactional data between a vendor's transaction terminal 21 and the electronic 
systems of the provider 25 and/or the processing system 16. For purposes of this 
specification, the transaction terminal 21 may comprise a card slot, Internet text field 
or most other mechanisms configured to receive account information or other 
electronic input. Transactional data may include transactional information from the 
merchant, such as pricing and vendor locator data. Data from the processing system 
16 may include approval of the credit request or other transaction. 
[0044] The identifying device 22 is preferably strongly personal to the user 23. 

That is, the user 23 typically has a type of access to the identifying device 22 that 
would be statistically unlikely for an unauthorized user to achieve. For instance, the 
identifying device 22 of one embodiment may be portable, and thus carried on or near 
the person of the user 23. Identifying devices 22 may include a cellular phone, a 
pager, a personal digital assistant (PDA) or a laptop computer, among others. 
[0045] The identifying device 22 is typically accessible to the user 23 at the 

time of a transaction. Additionally, the identifying device 22 is usually under the 
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personal and/or exclusive control of the user 23 and/or their assigns. A user 23 for 
purposes of this specification may thus comprise a single person or a collection of 
authorized users per application specifications. 

[0046] The portable and ubiquitous nature of cellular phones, pagers and other 

types of identifying devices furthers their practicality in some verification 
applications. However, one skilled in the art will appreciate that an identifying device 
22 may comprise virtually any device configured to transmit and receive a signal, to 
include devices that are dedicated and/or stationary, as well as a device having no 
function outside of the identification processes of the present invention. That is, a 
suitable identifying device may be constructed to communicate only between the user 
and the processing system 16, for example. However, where desired for economy 
considerations, devices commonly having application independent from transaction 
verification may be augmented with programming in accordance with the principles of 
the present invention. Moreover, such conventional devices may additionally be 
augmented with features that advance identification. Such features may include a BIR 
interface, such as a fingerprint reader and/or a voice recognition program associated 
with a cellular telephone. 

[0047] The identifying device 22 typically receives a number of inputs and 

outputs for communicating information externally. For interface with the user 23 and 
the processing system 16, the identifying device 22 typically includes an interface 
incorporating one or more user input devices (e.g., a keyboard, a mouse, a trackball, a 
joystick, a touch pad, smart card slot, retinal/fingerprint scanner, smart card/key, 
token detector and/or a microphone, among others) and a display (e.g., a CRT 
monitor, an LCD display panel, and/or a speaker, among others). 

17 



[0048] One skilled in the art will appreciate that most of the components 20- 

44 of Fig. 2 may be omitted and/or augmented in accordance with the principles of the 
present invention per application requirements. Moreover, the processes of one or 
more of the components 20-44 may be integrated with another component for 
application considerations. For instance, the account server 24 may include or 
otherwise incorporation functionality of the provider 25. Moreover, the functionality 
of the account server 24 may be included within the processing system 16. 
Furthermore, while shown with direct communication channels denoted by solid lines, 
one of skill in the art will appreciate that one or more of the components 20-44 of the 
processing system 16 may interconnect with the identifying device 22 using Internet 
or other network 32 connections. Fig. 2 shows networked connections in phantom. 
[0049] Those skilled in the art will recognize that the environments illustrated 

in Figs. 1 and 2 are not intended to limit the present invention. Indeed, those skilled 
in the art will recognize that other alternative hardware and/or software environments 
may be used without departing from the scope of the invention. One such 
environment is illustrated in Fig. 3. 

[0050] More particularly, while a typical transaction terminal comprises a card 

reader of a vender, aspects of the invention also apply to machine transactions and 
associated hardware. For instance, a transaction may include starting a vehicle. In 
such a scenario, the mere insertion of a key into an ignition block does not enable the 
user to start the vehicle. Such ignition is only realized when the transaction is 
authorized using remote identification data of the user. 

[0051] More particularly, the block diagram of Fig. 3 shows a system 50 for 

authenticating the identity of a plain or automobile operator 55. In terms analogous to 
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those of Fig. 2, the driver/pilot comprises a vehicle operator desiring authorization to 
initiate processes at a transaction terminal that includes an ignition switch 53. That is, 
the operator 55 wants to start the vehicle using the switch 53. In on scenario, the 
operator may begin an ignition sequence by inserting a key into the switch 53. In 
response to the ignition sequence at the switch 53 (e.g. key insertion), an authorization 
server 54 in communication with the ignition switch 53 directs a request for 
verification to a processing center 52. The processing center 52, in turn, generates and 
sends a request for remote identification data to an identifying device 5 1 that is 
accessible to the operator 55. 

[0052] The operator 55 enters remote identification data into the identifying 

device 51, which routes the remote identification data to the processing center 52. 
The processing center 52 compares the remote identification data to stored identifying 
data associated with the user 55. The comparison reveals whether the person 
purporting to be the pilot/driver 55 is, in fact, the driver/pilot authorized to operate the 
vehicle. A transaction involving the authentication system 50 may conclude with the 
processing center 52 enabling activation of the ignition switch 53. 
[0053] In another application of the invention, the processing center 52 may 

be collocated with the transaction terminal 53. For example, processing center 
circuitry housed within an ignition block may transmit a request for remote 
identification data to an identifying device 51 of the operator in response to insertion 
of a key. For additional security, transmission of the request may have a limited 
range, requiring the identifying device 5 1 to be in close proximity to the transaction 
terminal. 
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[0054] The flowchart 60 of Fig. 4 shows sequence steps suitable for execution 

within the hardware and software environments of Figs. 1-4. That is, Fig. 4 includes 
method steps for verifying the authenticity of an electronic transaction. In one sense, 
the steps may further authenticate the identity of a user 23 who desires access to credit 
or secured data. Moreover, the steps show transactional processes executed by the 
processing system 14 of Fig. 1. 

[0055] Prior to an electronic transaction, the processing system 16 receives an 

initial submission of identifying data from the user 23 at block 62. For instance, the 
user 23 may provide a password, token and/or a BLR to a service subscribing to, 
supporting or otherwise maintaining the processing system 16. The processing system 
16 may store the initial submission of identifying data at block 64 for future use. 
Namely, the processing system 16 uses the stored identifying data to verify captured 
identifying data, which is subsequently presented to the processing system 16 via the 
identifying device 22. 

[0056] Also prior to the transaction, the processing system 16 may generate 

and store user/system profiles 37 at block 66. While discussed below in greater detail, 
such profiles 37 may include rules regulating processing system 16 actions given 
certain operating parameters. For instance, a profile 37 may affect the functions of the 
processing system 16 regarding when, where and how the remote identification data is 
captured from the user 23. Another preliminary step at block 68 may include 
establishing or ensuring the vitality of communication links between the processing 
system 16 and the authentication server 24, as well as to the identifying device(s) 22 
that may be designated in a profile 37. In many commercial applications, the 
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processing system 16 maintains links for a plurality of identifying devices and for a 
number of different users. 

[0057] In operation, the processing system 16 receives a request for 

verification at block 70. The authentication request may arrive from the 
authentication server 24, or directly from the transaction terminal 21. The request for 
verification from the authorization server 24 may be in response to a merchant 
sending a transaction request to the authorization server 24 via the transaction 
terminal 21 . For instance, the user 23 may initiate a purchase for an airline ticket 
using conventional credit mechanisms, e.g., the terminal 21. The terminal 21 may 
prompt the authorization server 24 to create a verification request to the processing 
system 16. As such, processes consistent with embodiments of the present invention 
may compliment and augment some existing transaction systems, contributing 
dramatically to vendor, creditor/provider, user, and in the present instance, airline 
security without requiring major merchant capital expenditures on new equipment. 
[0058] In response to the request, the processing system 16 attempts to contact 

the identifying device 22 at block 72. Namely, the processing system 16 sends at 
block 72 a request for remote identification to the identifying device 22. The 
mechanism for delivery of the request for remote identification may depend in part 
upon the predetermined profile 37 of the user 23, as well as considerations regarding 
the hardware and programming inherent to the identifying device 22 utilized. For 
example, an identifying device 22 comprising a cellular telephone may receive the 
request for remote identification as routed from conventional cellular towers. An 
authentication device program may receive the request for remote identification via an 
internal or networked computer system connection. 
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[0059] Where so prescribed in a profile 37 associated with the user 23 and/or 

the system 10, the processing system 16 will respond to an unsuccessful attempt at 
block 74 by contacting the identifying device 22 with one or more subsequent 
attempts at block 76. The determination of a predetermined default plan at block 78 
will initiate execution of that plan at block 80. Otherwise, the processing system 16 
may end the transaction at block 92 by sending an appropriate notification back to the 
authentication server 24. 

[0060] Assuming the processing system 16 succeeds in making contact with 

the identifying device 22 at block 72, the user 23 may be prompted at block 82 to 
provide remote identification data to the identifying device 22. For instance, the user 
23 may be presented with a biometric interface configured to guide them through a 
process of submitting a live, or capture, BIR. More particularly, an automatic voice 
prompt on a telephone of a user 23 may ask the user 23 to speak a predetermined 
phrase if they desire the transaction to complete. Conversely, the phrase may be 
spoken where the user 23 does not wish the transaction to complete. Such a scenario 
may exist where the system 20 is set up to confirm that a transaction not be approved. 
[0061] To this end, appropriate software may launch a preferred biometric test 

at the identifying device 22 according to the preset parameters of a biometric 
verification sequence. A sequence may include a displayed user interface screen 
configured to cause the user to provide the voice or other capture remote identification 
data. For example, a fingerprint authentication application may prompt the user, 
"Place finger on scanner to approve the transaction." To this end, the request for 
remote identification may include pricing, merchant and other transactional 
information relating to the pending transaction. Where desired, a prompt of the 
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identifying device 22 may include a flashing light, audible alarm, vibration 
mechanism, or virtually any other feature configured to alert the user 23 of the 
communication from the processing system 16. 

[0062] The processing system 16 may receive from the identifying device 22 

the remote identification data at block 84. Where desired, the remote identification 
data may be retrieved from memory of the identifying device 22. Such may be the 
case where a user 23 has only recently submitted a capture BIR for the same or a 
different application. Where so configured, the program code 42 may download the 
recently stored capture BIR for submission to the processing system 16. Thus, one 
embodiment of the invention does not require the user to resubmit a capture BIR to 
realize remote identification. 

[0063] Where the processing system 16 fails to receive the remote 

identification data from the user 23 at block 84 within a predetermined amount of 
time, the processing system 16 may initiate an action to end the pending transaction at 
block 92. A similar action may be taken where a user 23 sends an active command 
back to the processing system 16 disaffirming the pending transaction. In either case, 
such precaution helps to prevent transactions unwanted by an account holder by 
requiring the user 23 to both access the identifying device 22 and to affirmatively 
approve the transaction with remote identification data. 

[0064] Remote identification data received from the user 23 at block 84 may 

be evaluated at block 86 to determine if it sufficiently matches the authentication data 
stored at block 64. Where such a match is determined at block 86, the processing 
system 16 may communicate verification to the account server 24 at block 88. 
Conversely, a determined failed match at block 90 may initiate another submission of 
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remote identification data from the user 23 back at block 82. Depending on the 
profile 37 of the user 23 and/or system 10, a failed match may alternatively end a 
pending transaction at block 92 by sending a denial signal to the merchant via the 
authentication server 24. Again per the applicable profile 37, the processing system 
16 may notify the user 23, provider 25 and/or account server 24 of the transaction 
status. In either case, pertinent details of successful and unsuccessful transactions 
may be recorded at block 94. 

[0065] As with the all of the figures discussed below, most any of the steps 

associated with Fig. 4 may be omitted, rearranged or augmented with additional steps 
in accordance with the principles of the present invention. Such changes merely 
constitute additional embodiments of the invention as suited to different operating 
environments and specifications. For instance, the remote identification data 
comparisons of blocks 84-86 of Fig. 4 maybe accomplished apart from the processing 
system 16 in certain embodiments of the invention. Furthermore, a match 
determination may alternatively occur at the identifying device 22 of the user 23. As 
such, the processing system 16 may alternatively receive the results of the 
determination from the identifying device 22, and communicate those results as before 
at block 88 or 92. 

[0066] Moreover, multiple devices 22 may be contacted at block 72, either in 

sequence or, effectively, simultaneously. In that case, the first device answered is 
used for purposes of the sequenced steps of Fig. 4. Such a scheme may be 
advantageous where a user 23 has both a cellular phone and a pager designated as 
their identifying device, but may only have one of them on their person at the time of 
a transaction. 
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[0067] According to another aspect of the invention, the authentication request 

of block 70 may be designated according to its urgency. For example, a request to 
authorize a purchase while a user 23 waits at a transaction terminal 21 may be 
programmatically designated as "priority." As such, the priority designation may 
ensure that there is no unreasonable in delay in conducting the entirety of the 
transaction. That is, the appropriate identifying device 22 is promptly contacted at 
block 72, and/or the user is timely prompted for identification data at block 82. 
Moreover, the relatively urgent nature of the priority designation may require that the 
user 23 submit the requisite approval data within a relatively short response time in 
order for the transaction to proceed. For example, the user 23 may be limited to a five 
minute period of time in which to submit the data. Such a predetermined transaction 
time period may commence when the user is first prompted for the data or in response 
to some other specified occurrence. 

[0068] If the data is not submitted within the timeframe, irrespective of its 

authenticity, the transaction may fail. Conversely, a lower priority request may allow 
the user 23 a number of hours, days or even or longer to respond to a prompt at block 
82. The prompt at block 82 may even be delayed, where appropriate. Such longer 
response times may have particular application where an item is ready to ship, 
pending approval by the user 23 within the response time. For instance, a user 23 not 
having access to their identifying device 22 at the time of a prompt may nonetheless 
permit the purchase to proceed online or by phone, but the transaction may not 
proceed until the user 23 has returned home or otherwise regained access to the device 
22. Where so desired, a user 23 who does not respond within a first transaction time 
period may be given a subsequent period, not necessarily contiguous with the first, in 
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which to respond in order to authorize the transaction. The present invention thus 
covers both realtime and delayed verification scenarios. 

[0069] The flowchart 100 of Fig. 5 shows steps taken by the user 23 of Fig. 2 

in accordance with the principles of the present invention. A user 23 may include one 
or more persons authorized for and/or attempting to access credit, information, 
equipment and/or services controlled by an (account) provider 25. The user 23 is 
typically registered prior to a transaction sequence, however, an initial transaction may 
include enrollment processes where appropriate. In either case, the user 23 may 
submit identifying data to the processing system 16 at block 102: Such identifying 
data may be stored in accordance with many conventional enrollment practices. The 
identifying data may include the type of data that can be subsequently repeated using 
their designated, identifying device(s) 22. For instance, a user 23 may use a number 
or text pad to key in a password into their pager or palm pilot. 
[0070] Where desired, a person whose authentication data is stored in 

connection with one creditor, account and/or operating system may enroll in a 
different application without having to accomplish conventional enrollment processes 
for that particular processing system or provider. The enrollment credential of the 
first application is automatically transferred to the second application as the new or 
updated enrollment credential for the second application. Such a process may save 
time for users, among other benefits. The general process of promoting enrollment 
identifying data is disclosed in International Application No. PCT/US02/29166, which 
was filed on September 13, 2002, is entitled "Credential Promotion," and is hereby 
incorporated by reference in its entirety. 
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[0071] Where required or desired, the user 23 may establish a profile 37 at 

block 104. While discussed below as the subject of Fig. 6, a profile 37 for purposes 
of Fig. 5 may include one or more rules affecting operation of a transaction's 
verification, to include the user's authentication. Such operating rules may dictate, for 
instance, which identifying devices 22 and/or types of remote identification data are to 
be used. While some such profiles 37 may include user preferences, other types of 
data comprising a profile 37 may include system level mandates. One such system 
profile attribute may stipulate the duration of an allotted window of time in which the 
user 23 must respond to a request for remote identification before a transaction 
becomes abandoned. 

[0072] Blocks 102-104 specifically show processes that regard establishing a 

user 23 within an authentication system 10. One of skill in the art will recognize that 
additional steps may be required and added in accordance with the underlying 
principles of the present invention, as such processes are widely known in the context 
of existing program enrollment. 

[0073] As shown in Fig. 5, the user 23 initiates a transaction at block 106. For 

example, the user 23 may communicate a desire to purchase an item to a merchant. In 
so doing, the user 23 may provide a form of account identification to the merchant. 
Such identification may comprise a conventional credit card, an account number, as 
well as a token created for the purpose of identifying the user 23. The identification 
may be received at a transaction terminal 21 . While described above in a commercial 
vending scenario, a transaction terminal 21 for purposes of this specification may 
comprise a card slot reader, a networked computer, a signal receiver or an ignition 
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switch, among other mechanisms configured generally to receive data relating to an 
account of the user 23. 

[0074] Where so configured, the submitted identification may undergo initial 

scrutiny at blocks 108-1 12 of Fig. 5. Such scrutiny may include processes similar to 
that described above in the context of conventional credit cards. That is, the 
processing system 16 may initially verify that an account exists for the proffered 
account. Another conventional initial verification may include presenting a signature 
for evaluation by the merchant at block 1 10 for initial screening/approval at block 
112. Due to the improved authentication processes of the present invention, these 
initial evaluation steps of blocks 108-1 12 may be scaled down or altogether omitted in 
certain applications. Where such evaluation is deemed unnecessary, for instance, then 
the processes of transaction may begin directly at block 114. 

[0075] Just as the inclusion or omission of blocks 108-1 10 may be determined 

by the profile 37 of block 104, so may application of the identifying processes at block 
1 14. That is, the user 23 or system 20 may have the option via the profile 37 to 
selectively determine whether to further activate transaction authentication processes. 
For instance, certain processes of the system 20 may only activate for purchase 
requests exceeding some preset monetary amount. That amount may be designated 
via a profile 37. In one embodiment, a user 23 may disable the system 20 using a 
button or switch on their identifying device 22. Such action may result in an 
otherwise conventional transaction. The same action in another scenario may halt 
further transactions. 

[0076] Where identifying processes in accordance with the principles of the 

present invention are desired and active at block 114 of Fig. 5, the user 23 may be 
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informed by the vendor at block 116 that secondary, identifying will be accomplished. 
Such notification may remind a user 23 to activate their identifying device 22 at block 
1 18, if not already powered. 

[0077] The user 23 receives a request for remote identification at their 

identifying device 22 at block 122. For example, the user 23 may receive a call on 
their cellular telephone instructing them to speak a password. The spoken password 
may comprise the remote identification data, as ascertained by voice recognition 
and/or biometric software. Prior to providing the remote identification data, certain 
embodiments of the present invention may require the user to log into the identifying 
device 22 at block 124, For example, the remote identification feature of a cellular 
phone or other identifying device 22 may be password or BER protected. In one 
embodiment, a user 23 may be required to enter the password (or BER, where 
appropriate) prior to activating the identifying device 22 and responding to the request 
for remote data at block 122. 

[0078] A user 23 may confirm the particulars of a pending transaction using 

the request for remote identification. For instance, a prompt on a pager at block 524 
of Fig. 5 may display text, "Enter code if you wish to approve $400 for groceries." 
Confirmation of such pricing and other information at block 126 prior to authorization 
may thus provide an additional measure of security. For instance, where the reported 
pricing information is in error, the user 23 may effectively cancel or delay the 
transaction. The discrepancy may thus be addressed with the merchant at block 128 
before the user's account is credited. Where the user 23 alternatively desires to 
approve the expenditure at block 524, the remote identification data is provided to the 
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identifying device 22 by the user 23 at block 130. The user 23 at block 130 has then 
completed all steps necessary to realize the transaction at blocks 132 and 134. 
[0079] The flowchart 140 of Fig. 6 shows steps suited to generate a profile 37 

in accordance with the principles of the present invention. As discussed herein, a 
profile 37 generally regards a set of system 20 and/or user 23 stipulated rules that 
affect operation of transaction verification. Profiles 37 may be established prior to an 
electronic transaction to add an additional degree of security and convenience, as well 
as to streamline authorizations and/or transactions. 

[0080] At block 142, the user 23 and/or a system administrator may determine 

for which type of transactions the processes of the present invention will activate. For 
instance, there may be certain types of "low risk" transactions for which the user 23 
may not desire identification processes. For instance, a profile 37 may not initiate 
verification processes for historically regular or otherwise designated types of 
purchases. Another profile 37 attribute may be directed to the time of day that a 
transaction occurs. For example, the user 23 may wish at block 144 to have any 
purchase occurring after eight o'clock p.m. to be personally authenticated using 
transaction verification processes. As such, the profile 37 may be augmented to 
reflect the designated time at block 146. 

[0081] Similarly, a user 23 or system administrator may desire at block 148 to 

have only Internet purchases verified using the transaction verification processes. The 
profile 37 of another or the same embodiment may require verification processes for 
any purchase of over fifty dollars. The determined type of transaction at block may 
further dictate the type and quantity of remote identification data required for 
authentication. For instance, a profile set up by an employer may require that each 
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purchase above a limit made using a corporate credit card be authenticated using at 
least two of a password and a voice and/or fingerprint. While such settings may be 
readily accomplished at blocks 148-154 of Fig. 6, it should be appreciated by one of 
skill in the art that virtually any quantifiable metric regarding a transaction may be 
additionally used to screen or initiate authentication processes that are in accordance 
with the present invention. 

[0082] Profiles 37 may also stipulate a preference for the identifying device 22 

to be used in the transaction. For example, a user 23 may programmatically designate 
a cellular telephone as being their primary identifying device 22 at block 156. Where 
desired, the user 23 may also designate secondary, or back-up, devices at blocks 158- 
160. However, it should be appreciated that secondary devices 22 within the same 
embodiment may actually act as primary identifying devices 22 under certain 
conditions. For example, a profile 37 may stipulate that transactions used to start an 
automobile use a receiver on a key chain as an identifying device 51, while all other 
transactions use a pager, instead. 

[0083] The profile 37 of one embodiment may additionally employ multiple 

identifying devices 22 in a single transaction. For instance, a user 23 may have to 
submit a fingerprint to a cell phone, as well as type a password into a PDA. Another 
or the same profile allows a user 23 or administrator of the user's account to select the 
identifying device(s) and/or the type of remote identification data used in a 
transaction. For example, the cellular phone of a user may prompt, "Do you want to 
confirm the transaction using your voice signature or your password?" Another 
prompt, "Please don't ask me again," may save the settings selected by the user or 
administrator. 
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[0084] While such preferences may be programmed into a given profile 37 by 

the user 23, profiles 37 of other or the same embodiments may include system level 
preferences. Such system level preferences may reflect a policy intended to affect all 
or a designated number of users 23 serviced by a processing system 16, for instance. 
Thus, a system preference may apply to a network, a subsystem/cluster, or a group of 
user accounts. By virtue of this feature, an account manager or other administrator 
can designate groupings of users having the particular security requirements mandated 
by the system policy. Tags relating to these requirements or settings may be 
programmatically attached to a database field associated with the designated users 23 
and maintained at the authorization server 24 or processing system 16. A transaction 
may then initiate access of these database fields to determine the appropriate 
identifying device(s) 22. 

[0085] A preference affecting system policy in one embodiment may include a 

confidence rating. A confidence rating may be assigned by an administrator in view 
of reliability and security considerations of different types of identifying devices 22 
and/or remote identification data. Confidence ratings may be assigned to, for 
instance, an identifying device 22 and/or a specific type of an authentication 
transaction. In operation, an administrator may assign a higher confidence rating to an 
identifying device 22 having security standards known to be higher than those of a 
more easily compromised, secondary device. 

[0086] As such, the system 20 may select a most appropriate identifying 

device 22 having the higher confidence rating to use in a given transaction. For 
example, the program code 40 may select a telephone accommodating a fingerprint 



32 



BIR over a smart card reader. Yet another suitable profile 37 instituted by a system 
administrator may include random device selection features. 
[0087] In an effort to automatically determine an appropriate identifying 

device 22, the system 20 may make an accounting of which biometric or other 
authentication devices are currently assigned to a user 23 and/or installed on a given 
identifying device 22. For instance, a local computer 102 of the user may be 
equipped with both fingerprint and retinal biometric testing devices. Proprietary 
programs associated with conventional biometric testing devices (including BioAPI 
code 38) place a marker within a registry of the laptop 102 or other identifying device 
22 upon installation and de-installation. This registry provides a mechanism for the 
system 20 to assess available devices 22. Another or the same embodiment may rely 
on processes that enumerate available devices in real time, or at the time of 
transcription, thus providing the system 20 with an accounting of appropriate devices. 
[0088] The profile preferences discussed herein in the context of driving an 

authentication selection process are included only for exemplary purposes. 
Accordingly, preferences may be omitted, altered and supplanted with others in 
accordance with the principles of the present invention. While some such preferences 
may be discriminating, others may simply sequence through an entire list of retrieved 
devices before finding one that is compatible with subsequently implemented policies. 
In any case, any number of alternative programs configured to suit the specific needs 
of the network system 20 may be used to determine an identifying device 22 from 
which to retrieve remote identification data. 

[0089] The profile 37 may be programmed with instructions at block 162 that 

specifies actions to be taken by the processing system 16 in the absence of a match of 
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the captured and stored authentication data. Such actions may include a specified 
number of reattempted matches, designated secondary devices, as well as the denial of 
a transaction. The system 10 at block 164 may further include information within the 
same profile 37 that stipulates the period, or window, of time within which a user 23 
must respond to a request for remote identification in order to avoid abandonment of 
the electronic transaction. 

[0090] At blocks 166-168 of Fig. 6, the profile 37 may be programmed with 

controls intended to prohibit or channel specified transactions. For example, such 
controls may be used by parents or authorized officials to prevent juveniles from 
accessing websites hosting objectionable content. Other controls may halt 
commercial credit transactions deviating from a preset budget of the user 23, 
irrespective of their actual credit limit. Still another profile 37 may act to prevent 
vehicular offenders from accessing an automobile during certain hours. 
[0091] A user 23 or system administrator may account for BIR update 

procedures and activity logs at blocks 170 and 172 of Fig. 6, respectively. For 
instance, a suitable BIR update may include storing remote identification data in the 
place of previously stored BIR data as discussed above. Logged activity may include 
transactional and pricing data as desired for security and accountability purposes. 
[0092] While the present invention has been illustrated by the description of 

embodiments thereof, and while the embodiments have been described in 
considerable detail, it is not intended to restrict or in any way limit the scope of the 
appended claims to such detail. Additional advantages and modifications will readily 
appear to those skilled in the art. For example, identifying data, remote identification 
data and other identifying information may be encrypted at any step delineated in the 

34 



above-discussed flowcharts in accordance with the principles of the present invention. 
[0093] Furthermore, multiple users may be allowed or required to participate 

in a single transaction verification sequence. For instance, a first user may initiate a 
transaction at terminal, while a second user is contacted via their own identifying 
device in response to the initiation of the transaction (by the first user). The second 
user may enter the remote identification data in response to the prompt, which is 
compared against the stored identifying data of the second user. The second user 
typically enters the remote identification data only after they have been given an 
opportunity to approve the particulars of a transaction. For example, a corporation, 
government office or parent may review and approve purchases made by an employee, 
civil servant, or teenager, respectively. 

[0094] As such, the person or persons authorizing the transaction may not 

include the person attempting an actual purchase. For instance, an employee may 
attempt to make an expensive purchase on a corporate credit card. Per the applicable 
profile 37, the elevated cost may require transactional approval from both a manager 
and a corporate accountant. In another or the same instance, a supervisor may 
override the approval of another person who is otherwise authorized to verify a 
transaction. Still another profile 37 may require approval from some percentage or 
breakout of a group of authorized users. Where so configured, a processing center my 
concurrently or otherwise near simultaneously contact the respective identifying 
devices of multiple users who are all authorized to verify a transaction. As such, the 
first of the multiple users to answer their respective identifying device or submit the 
remote identification data may effectively control the outcome of the transaction 
verification. One skilled in the art will appreciate that a profile 37 for purposes of this 
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specification may include nearly any conceivable rule or scheme, to include time- 
based, or sequential approvals where applicable. For instance, a first user may 
approve a transaction only after a first has given their own approval. 
[0095] Where desirable, any number of delegates may be permitted to 

authorize a transaction as the authorized user. A delegate comprises a person or group 
of people having permission to enter their own remote identification data to authorize 
a transaction on behalf of the user having the account. Using remote identification 
data correlated to themselves, a delegate authorizes a transaction as the actual user. 
[0096] For example, a spouse may initiate an online transaction at a 

transaction terminal comprising an Internet station kiosk at an airport. As a delegate, 
the spouse may enter identifying data unique to her husband's account. For example, 
the spouse may type into a computer field the number printed on the credit card of her 
husband. A request for verification generated in response to the activity at the kiosk is 
sent to a processing center. In one scenario, the processing center contacts all of the 
identifying devices assigned to the husband's account. Those identifying devices 
assigned to the account may include not only those associated with the husband, but 
also those assigned to persons designated as a delegate to the account, e.g., the spouse. 
[0097] In the present case, the spouse is assigned to the account as a delegate. 

Records at the processing center show that the spouse (designated as a delegate) has 
specified her cellular phone as her primary identifying device. Where the identifying 
device of the husband is a pager, the processing center may communicate a request for 
remote identification data to both the cellular phone of the wife and the pager of her 
husband. The first of the spouses to answer their respective identifying device is then 
prompted to enter their remote identification data. 
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[0098] Should the wife answer her cellular phone first, for example, the 

identifying device prompts her to enter her personal, unique pin number to authorize 
the online transaction using her husband's account. The submitted remote 
identification data is matched against authentication data stored in association with 
the account at the processing center, for instance. The stored association may include 
a database comprising a list of delegates privileged to use the husband's account to 
verify transactions as the husband, himself. The database further includes stored 
authentication data for each delegate. As such, a match of the wife's pin to the stored 
pin associated with the wife (and as a delegate of her husband) enables authorization 
of the transaction just as if the husband, himself, had submitted his own remote 
identification data. 

[0099] As an alternative to communicating a request for remote identification 

to the user and all assigned delegates, a delegate may designate their own personal 
identifying device at the time the transaction is initiated. For example, the wife in the 
above example may include in the identifying data submitted to the transaction 
terminal a delegate identifier, such as a pin code preceding the card number, that alerts 
the processing system as to the delegate status of the wife. As such, the processing 
system may contact only the identifying device of the delegate after processing the 
identifying data. The wife is then prompted to submit her remote identification data 
as before. 

[0100] An analogous process of logging a delegate user into an account of a 

principal user as the principal is disclosed in International Publication No. WO 
03/075135 Al, which was published on September 12, 2003, is entitled "User Login 
Delegation," and is hereby incorporated by reference in its entirety. As used therein, a 
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"delegate user" is a "delegate" for purposes of this specification, and a "principle 
user" is referred to herein as "user." Actions taken by the delegate while acting on 
behalf of the user may be recorded for evaluation and accountability considerations. 
Delegates privileged to privileged to act on behalf of the user are added and deleted to 
the database as necessary. 

[0101] While embodiments discussed herein primarily involve the user 23 

actively submitting remote identification data, other embodiments may passively 
acquire the remote identification data. For example, such data may comprise 
proximal information indicative of the user's position relative to a transaction 
terminal 2 1 or some other predetermined location. As such, a user may wear an 
identifying device 22 comprising a transmitter. The transmitter may further include a 
global positioning system (GPS) or other receiver configured to determine a position 
relative to a known location or transponder. Such a location may be communicated 
from the transaction terminal 21 along with the request for verification. 
[0102] The processing system 16 may then compare stored identifying data 

comprising the location of the transaction terminal 21 against the remote identification 
data, which comprises the location of the GPS receiver/identifying device 22. When 
the GPS location communicated from the identifying device 22 matches within 
predetermined parameters the general coordinates/zip code of the transaction terminal 
22, the processing system 16 sends verification back to the transaction terminal 22. 
This configuration thus imputes additional security into a transaction by virtue of 
requiring the identifying device 22 to be proximate the user 23/transaction terminal 22 
for added security. 
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[0103] While a typical transaction begins with the presentation of identifying 

data at the transaction terminal 21, another transaction may include an initial step 
involving the identifying device 22 reading data from a bar code or port, for instance, 
of a transaction terminal 21 . More particularly, a user may read or cause data to be 
entered into the identifying device 22 that may be used to identify a given transaction 
terminal 21 to the processing system 16. Such a scenario may be desirable where, for 
instance, a user 23 plans on making a purchase at the transaction terminal 21, but 
wished to avoid any delays associated with verifying the transaction while at the 
terminal 21. As such, this feature may allow a transaction to be pre-verified. That is, 
when the user 23 later initiates the purchase at the transaction terminal 21, the 
processing system 16 is effectively on notice, waiting for the request for verification 
to arrive from the transaction terminal 21. 

[0104] When the request is received, the processing system 16 may send 

verification back to the transaction terminal 21 without first prompting the user 23 to 
enter remote identification data for approval. To this end, the data scanned, recalled 
from memory, read or otherwise received that identifies the transaction terminal 21 is 
communicated directly from the identifying device 22 to the processing system 16 
along with remote identification data, for instance, prior to the user submitting 
identifying data at the transaction terminal. As such, the processing system 16 may 
already have the data needed to authorize or pre-approve the transaction before the 
user 23 presents the identifying data to the transaction terminal 21 . 
[0105] One of skill in the art will appreciate that the sequence of the steps in 

the included flowcharts may be altered, to include omitting certain processes without 
conflicting with the principles of the present invention. Similarly, related or known 
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processes can be incorporated to complement those discussed herein. It should 
furthermore be understood that the embodiments and associated programs discussed 
above are compatible with most known enrollment processes and may further be 
optimized to realize even greater efficiencies. For instance, a program that locally 
stores BIR data in response to a successful login/enrollment may be complimented by 
features of the present invention. The general process of locally storing biometric 
data in response to a successful login is disclosed in International Application No. 
PCT/US01/30458, which was filed on September 28, 2001, is entitled "Biometric 
Record Caching," and is hereby incorporated by reference in its entirety. The 
invention in its broader aspects is, therefore, not limited to the specific details, 
representative apparatus and method, and illustrative examples shown and described. 
Accordingly, departures may be made from such details without departing from the 
spirit or scope of the general inventive concept. 
[0106] Having described the invention, what is claimed is: 
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